@cspiel1 can you review and test with your SNI setup?

Yes, I'll try to do so. It will take some time to arrange the setup. Maybe I have to ask also our QA team.

By means of debugging I could verify that the correct certificate was selected. But then I had no luck with the cert verification on the callee (TLS server side), also in main branch. The next two days will be difficult to work on this.

I am coming closer with the test setup. Will have a result soon.

I have some troubles:

• The callee (TLS server) seems to verify the client certificate incl host name check. sip_verify_client no seems to make no difference.
• It seems that the setting sip_capath does not work.

• The callee (TLS server) seems to verify the client certificate incl host name check. sip_verify_client no seems to make no difference.

Not sure why, but verify client is always enabled for SNI here:

• It seems that the setting sip_capath does not work.

It works for test, does it also not work with main?

Beside of these issues, that also occur in main branch this PR seems to be okay. SNI works.

tls: tls_verify_handler: subject_name = /C=AU/ST=Some-State/O=Retest/CN=Mr Retest Root CA
tls: tls_verify_handler: issuer_name  = /C=AU/ST=Some-State/O=Retest/CN=Mr Retest Root CA
tls: tls verify ok = 1
tls: tls_verify_handler: subject_name = /C=AU/ST=Some-State/O=Retest/CN=Mr Retest Intermediate CA
tls: tls_verify_handler: issuer_name  = /C=AU/ST=Some-State/O=Retest/CN=Mr Retest Root CA
tls: tls verify ok = 1
tls: tls_verify_handler: subject_name = /C=AU/ST=Some-State/O=Retest/CN=server.foo.local
tls: tls_verify_handler: issuer_name  = /C=AU/ST=Some-State/O=Retest/CN=Mr Retest Intermediate CA
tls: tls verify ok = 1

With another cert chain, and a second account it works also. But as mentioned above, the sip_cafile has to be set to the second chain.

The code looks good. I suggest to merge this.

Not sure why, but verify client is always enabled for SNI here:

Ah, ok. Not sure if this is wanted.

It works for test, does it also not work with main?

Yes. This should be analysed further.

@sreimers I have noticed that this PR changed the behavior quite a bit. Was that on purpose?

E.g. if the peer does not add the server_name extension, then the handshake always fails now. Before, the handshake proceeded.

There are different options to choose a certificate. E.g. Certificates configured in accounts. Or globally in config file.

Thus a missing server_name should not be the reason that TLS handshake fails. As soon as a wrong certificate or no certificate is offered the TLS handshake should fail.

@sreimers I have noticed that this PR changed the behavior quite a bit. Was that on purpose?

I think this is a bug, can you try:

diff --git a/src/tls/openssl/sni.c b/src/tls/openssl/sni.c
index 8298e40f..8be0e7f7 100644
--- a/src/tls/openssl/sni.c
+++ b/src/tls/openssl/sni.c
@@ -166,10 +166,8 @@ static int ssl_servername_handler(SSL *ssl, int *al, void *arg)
        const char *sni;
 
        sni = SSL_get_servername(ssl, TLSEXT_NAMETYPE_host_name);
-       if (!str_isset(sni)) {
-               *al = SSL_AD_UNRECOGNIZED_NAME;
-               return SSL_TLSEXT_ERR_ALERT_FATAL;
-       }
+       if (!str_isset(sni))
+               return SSL_TLSEXT_ERR_OK;
 
        /* find and apply matching certificate */
        uc = tls_cert_for_sni(tls, sni);

Implemented in

• tls/sni: skip SNI check if we are client or server_name absent #1169